---
title: Hybrid
---

<Info>
**Important**
The Hybrid deployment option requires an [Enterprise](/langgraph-platform/plans) plan.
</Info>

## Requirements

* You use `langgraph-cli` and/or [LangGraph Studio](/langgraph-platform/langgraph-studio) app to test graph locally.
* You use `langgraph build` command to build image.

## Hybrid

The [Hybrid](/langgraph-platform/deploy-hybrid) deployment option lets you manage the [data plane](/langgraph-platform/data-plane) in your own cloud, while we handle the [control plane](/langgraph-platform/control-plane) in ours. When using the Hybrid version, you authenticate with a [LangSmith](https://smith.langchain.com/) API key.

|                   | [Control plane](/langgraph-platform/control-plane) | [Data plane](/langgraph-platform/data-plane) |
|-------------------|-------------------|------------|
| **What is it?** | <ul><li>Control plane UI for creating deployments and revisions</li><li>Control plane APIs for creating deployments and revisions</li></ul> | <ul><li>Data plane "listener" for reconciling deployments with control plane state</li><li>LangGraph Servers</li><li>Postgres, Redis, etc</li></ul> |
| **Where is it hosted?** | LangChain's cloud | Your cloud |
| **Who provisions and manages it?** | LangChain | You |

For information on how to deploy a [LangGraph Server](/langgraph-platform/langgraph-server) to Hybrid, see [Deploy to Hybrid](/langgraph-platform/deploy-hybrid)

### Architecture

![Hybrid deployment: LangChain-hosted control plane (LangSmith UI/APIs) manages deployments. Your cloud runs a listener, LangGraph Server instances, and backing stores (Postgres/Redis) on Kubernetes.](/langgraph-platform/images/hybrid-architecture.png)

### Compute Platforms

* **Kubernetes**: The Hybrid deployment option supports deploying data plane infrastructure to any Kubernetes cluster.

<Tip>
If you would like to deploy to Kubernetes, you can follow the [Hybrid deployment guide](/langgraph-platform/deploy-hybrid).
</Tip>

## Listeners

In a hybrid deployment, one or more ["listener" applications](/langgraph-platform/data-plane#”listener”-application) can be deployed depending on the organization of LangSmith workspaces and Kubernetes clusters.

**Kubernetes cluster organization**
- One or more listeners can be deployed on a Kubernetes cluster.
- A listener can be configured to deploy to one or more Kubernetes namespaces in the cluster.
- The owner of the Kubernetes cluster is responsible for the optimal organization of listeners for their use case. This involves carefully planning how LangGraph Server deployments should be structured in advance.

**LangSmith workspace organization**
- A workspace can have one or more listeners associated with it.
- LangGraph Server deployments in a workspace can only be deployed to Kubernetes clusters where all the workspace listeners are also deployed.

### Use Cases

The following provides a non-exhaustive list of examples for configuring listeners based on the organization of your LangSmith workspaces and Kubernetes clusters. However, these are not strict requirements.

#### Each LangSmith workspace deploys to a separate Kubernetes cluster

Example:
- Kubernetes cluster `alpha` is for workspace `A`
- Kubernetes cluster `beta` is for workspace `B`

#### Each LangSmith workspace deploys to a separate Kubernetes cluster, but “dev” workloads can be deployed to a shared Kubernetes cluster

In this use case, mulitple LangSmith workspaces deploy to a single Kubernetes cluster.

Example:
- Kubernetes cluster `alpha` is for workspace `A`
- Kubernetes cluster `beta` is for workspace `B`
- Kubernetes cluster `dev` is for workspaces `A` and `B`
- Both workspaces have two listeners associated with them
- Kubernetes cluster `dev` has two listener deployments

#### Deploy to one Kubernetes cluster, in one Kubernetes namespace

Example:
- Kubernetes cluster `alpha` is for workspace `A`
- Kubernetes cluster `alpha` is for workspace `B`

#### Deploy to one Kubernetes cluster, but in multiple Kubernetes namespaces

Example:
- Kubernetes cluster `alpha` and namespace `1` is for workspace `A`
- Kubernetes cluster `alpha` and namespace `2` is for workspace `B`
